iptunnel: add support to ipip, ipip6 and ip6ip6 tunnels #167

liangwen12year · 2025-05-19T01:21:15Z

iptunnel: add support to ipip, ipip6 and ip6ip6 tunnels

All these tunnels use the IFLA_IPTUN_* netlink API. Therefore, both
IFLAN_INFO_KIND "ipip" and "ip6tnl" data is serialized using the
IpTunnel struct.

Unit tests added.

cathay4t · 2025-05-19T06:35:05Z

src/link/link_info/iptunnel.rs

+                        )?,
+                    )))
+                }
+                _ => {


There is no default in kernel for parsing this:

net/ipv4/ip_tunnel_core.c 1158: if (data[IFLA_IPTUN_FLAGS]) { 1161: flags = nla_get_be16(data[IFLA_IPTUN_FLAGS]); net/ipv6/ip6_tunnel.c 1992: if (data[IFLA_IPTUN_FLAGS]) 1993: parms->flags = nla_get_u32(data[IFLA_IPTUN_FLAGS]); 2104: /* IFLA_IPTUN_FLAGS */ 2134: nla_put_u32(skb, IFLA_IPTUN_FLAGS, parm->flags) || 2170: [IFLA_IPTUN_FLAGS] = { .type = NLA_U32 }, net/ipv6/sit.c 1668: /* IFLA_IPTUN_FLAGS */ 1708: nla_put_be16(skb, IFLA_IPTUN_FLAGS, 1748: [IFLA_IPTUN_FLAGS] = { .type = NLA_U16 },

Always do explicit kind matching and fail for unknown kind.

I added the explicit kind matching and fail for an unknown kind.

cathay4t · 2025-05-19T06:37:44Z

src/link/link_info/iptunnel.rs

+                    Flags(TunnelFlags::from_bits_retain(u32::from(
+                        parse_u16(payload).context(
+                            "invalid IFLA_IPTUN_FLAGS value for SIT",
+                        )?,


Instead of storing u16 into u32.

I prefer InfoIpTunnel::Ipv6SitFlags(u16), InfoIpTunnel::Ipv6Flags(u32), InfoIpTunnel::Ipv4Flags(u16).

I added InfoIpTunnel::Ipv6SitFlags(u16), InfoIpTunnel::Ipv6Flags(u32), InfoIpTunnel::Ipv4Flags(u16) as you suggested.

cathay4t · 2025-05-19T06:39:57Z

src/link/link_info/iptunnel.rs

+            | Ipv6RdRelayPrefixLen(value) => {
+                NativeEndian::write_u16(buffer, *value)
+            }
+            Protocol(value) => buffer[0] = i32::from(*value) as u8,


The as is dangerous keyword because it discard data silently.

According to https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml , it is always u8.

So implement From<u8> for IpProtocol there instead of using as. When you do that, please fix src/rule/attribute.rs also.

I implemented From<u8> for IpProtocol instead of using as. I also fixed src/rule/attribute.rs.

cathay4t

Please also include unit test for ipv6 site support.

All these tunnels use the IFLA_IPTUN_* netlink API. Therefore, both IFLAN_INFO_KIND "ipip" and "ip6tnl" data is serialized using the IpTunnel struct. Unit tests added. Signed-off-by: Fernando Fernandez Mancera <[email protected]>

According to the IANA protocol number specification (https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml), protocol numbers are always within the u8 range. Using `as` for type conversion is dangerous because it can silently discard higher-order data, leading to bugs that are hard to detect. This change ensures all protocol number conversions are type-safe and explicit, avoiding accidental data loss and aligning the code with the protocol specification.

codecov · 2025-05-26T02:24:30Z

Codecov Report

Attention: Patch coverage is 64.53202% with 72 lines in your changes missing coverage. Please review.

Project coverage is 67.83%. Comparing base (201d99b) to head (cbb7c22).
Report is 20 commits behind head on main.

Files with missing lines	Patch %	Lines
src/link/link_info/iptunnel.rs	59.32%	72 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #167      +/-   ##
==========================================
+ Coverage   67.41%   67.83%   +0.42%     
==========================================
  Files         140      142       +2     
  Lines        9508     9925     +417     
==========================================
+ Hits         6410     6733     +323     
- Misses       3098     3192      +94

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

liangwen12year · 2025-05-26T16:52:50Z

Please also include unit test for ipv6 site support.

Thanks, I added the unit test for the sit support.

qinqon · 2025-05-28T07:54:59Z

src/link/link_info/infos.rs

@@ -188,7 +189,8 @@ pub enum InfoKind {
    MacVtap,
    GreTap,
    GreTap6,
-    IpTun,


Don't this breaks retrocompatibility ? maybe we need to transform IpTun into an alis to IpIp

It is ok to break API before we reach 1.0.

This IpTun is clearly wrong because kernel use ipip string.

fair enough

qinqon · 2025-05-28T07:55:33Z

src/link/link_info/iptunnel.rs

+const IFLA_IPTUN_LINK: u16 = 1;
+const IFLA_IPTUN_LOCAL: u16 = 2;
+const IFLA_IPTUN_REMOTE: u16 = 3;
+const IFLA_IPTUN_TTL: u16 = 4;
+const IFLA_IPTUN_TOS: u16 = 5;
+const IFLA_IPTUN_ENCAP_LIMIT: u16 = 6;
+const IFLA_IPTUN_FLOWINFO: u16 = 7;
+const IFLA_IPTUN_FLAGS: u16 = 8;
+const IFLA_IPTUN_PROTO: u16 = 9;
+const IFLA_IPTUN_PMTUDISC: u16 = 10;
+const IFLA_IPTUN_6RD_PREFIX: u16 = 11;
+const IFLA_IPTUN_6RD_RELAY_PREFIX: u16 = 12;
+const IFLA_IPTUN_6RD_PREFIXLEN: u16 = 13;
+const IFLA_IPTUN_6RD_RELAY_PREFIXLEN: u16 = 14;
+const IFLA_IPTUN_ENCAP_TYPE: u16 = 15;
+const IFLA_IPTUN_ENCAP_FLAGS: u16 = 16;
+const IFLA_IPTUN_ENCAP_SPORT: u16 = 17;
+const IFLA_IPTUN_ENCAP_DPORT: u16 = 18;
+const IFLA_IPTUN_COLLECT_METADATA: u16 = 19;
+const IFLA_IPTUN_FWMARK: u16 = 20;


Maybe an enum is better here ?

#[repr(u16)] enum IPTunKind { Link Local Remove } The values are consecutive calculated by rust

repr(u16) will not works for Other(u16) for as transmute. And using repr forbid rust to find smaller datatype for this enum. So using repr brings no benefit.

qinqon · 2025-05-28T08:09:32Z

src/link/link_info/iptunnel.rs

+                if payload.len() == 4 {
+                    let mut data = [0u8; 4];
+                    data.copy_from_slice(&payload[0..4]);
+                    Self::Local(IpAddr::V4(Ipv4Addr::from(data)))
+                } else if payload.len() == 16 {
+                    let mut data = [0u8; 16];
+                    data.copy_from_slice(&payload[0..16]);
+                    Self::Local(IpAddr::V6(Ipv6Addr::from(data)))


I see this pattern quite repeated like, ipv4 vs ipv6 can you factor that out ?

I think we already have parse_ip_addr().

Then let's use it.

I used parse_ip_addr() instead, thanks!

qinqon · 2025-05-28T08:12:22Z

src/link/link_info/iptunnel.rs

+pub enum TunnelEncapType {
+    None = TUNNEL_ENCAP_NONE,
+    Fou = TUNNEL_ENCAP_FOU,
+    Gue = TUNNEL_ENCAP_GUE,
+    Mpls = TUNNEL_ENCAP_MPLS,
+    Other(u16),
+}


Why do we need the constants here, I think you can directly use TunnelEncapType::[Kind] everywhere

We should not.

The Other thing ?

I think that we need constants in the Rust code to provide an explicit and stable mapping between each enum variant and its corresponding protocol value as defined by the kernel. Using constants such as TUNNEL_ENCAP_FOU or TUNNEL_ENCAP_GUE ensures that the integer values we use in serialization and deserialization always match the values expected by the kernel, regardless of the order of enum variants in Rust or any future refactoring.

This improves the maintainability and clarity of the code by making protocol mappings immediately clear to anyone reading the code.

qinqon · 2025-05-28T08:13:09Z

src/link/link_info/iptunnel.rs

+impl From<u16> for TunnelEncapType {
+    fn from(d: u16) -> Self {
+        match d {
+            TUNNEL_ENCAP_NONE => Self::None,
+            TUNNEL_ENCAP_FOU => Self::Fou,
+            TUNNEL_ENCAP_GUE => Self::Gue,
+            TUNNEL_ENCAP_MPLS => Self::Mpls,
+            _ => Self::Other(d),
+        }
+    }
+}
+
+impl From<TunnelEncapType> for u16 {
+    fn from(d: TunnelEncapType) -> Self {
+        match d {
+            TunnelEncapType::None => TUNNEL_ENCAP_NONE,
+            TunnelEncapType::Fou => TUNNEL_ENCAP_FOU,
+            TunnelEncapType::Gue => TUNNEL_ENCAP_GUE,
+            TunnelEncapType::Mpls => TUNNEL_ENCAP_MPLS,
+            TunnelEncapType::Other(value) => value,
+        }
+    }
+}


This is not really needed if we just use the const with the reprt everywhere.

[repr] should not be used as the as action will not works for enum with Other(u32) variant.

liangwen12year force-pushed the ipip_support branch 4 times, most recently from 669f960 to 24fa311 Compare May 19, 2025 02:23

cathay4t requested changes May 19, 2025

View reviewed changes

ffmancera and others added 2 commits May 21, 2025 20:53

iptunnel: add support to ipip, ipip6 and ip6ip6 tunnels

2704b97

All these tunnels use the IFLA_IPTUN_* netlink API. Therefore, both IFLAN_INFO_KIND "ipip" and "ip6tnl" data is serialized using the IpTunnel struct. Unit tests added. Signed-off-by: Fernando Fernandez Mancera <[email protected]>

liangwen12year force-pushed the ipip_support branch 2 times, most recently from a75e419 to cbb7c22 Compare May 26, 2025 02:23

liangwen12year force-pushed the ipip_support branch from cbb7c22 to e2a2c44 Compare May 26, 2025 02:32

qinqon suggested changes May 28, 2025

View reviewed changes

liangwen12year force-pushed the ipip_support branch from e2a2c44 to 0f97da2 Compare May 28, 2025 12:57

fixup! iptunnel: add support to ipip, ipip6 and ip6ip6 tunnels

5b9a3a8

liangwen12year force-pushed the ipip_support branch from 0f97da2 to 5b9a3a8 Compare May 28, 2025 15:59

iptunnel: add support to ipip, ipip6 and ip6ip6 tunnels #167

Are you sure you want to change the base?

iptunnel: add support to ipip, ipip6 and ip6ip6 tunnels #167

Uh oh!

Conversation

liangwen12year commented May 19, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cathay4t left a comment

Choose a reason for hiding this comment

Uh oh!

codecov bot commented May 26, 2025

Codecov Report

Uh oh!

liangwen12year commented May 26, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!